20+ Years in Agile and Counting
There are a number of ways of approaching agile as a methodology for your team, and a larger number of ways to become overwhelmed and confused. A good sign that you've lost focus on your work is when team members start debating...whether something is agile or not.
We're not trying to "be agile", we're trying to deliver value. Agile is just one of the tools we use to help us along the way.
Over the last couple of years I've had the opportunity to create two development teams from scratch. This provided a perfect opportunity to introduce agile practices, while leaning on nearly 20 years of experince running and contributing to agile projects. One option would have been to point the team to scrum.org and set about implementing the full set of scrum processes. I suspect that this would have been the approach had I hired a professional Scrum Master.
This article is particularly aimed at people who are either confused/intimidated by agile, or who are anxious that they aren't doing agile "properly" enough. What I hope to show here is that "it's all about scale". The best teams select the tools and techniques that they need to execute at the right quality and scale for thier project. They don't waste time on ceremonies and processes that don't add value.
Work Management vs Technical Excellance
When we build software we're actually doing two things simultaneously:
- Building the software
- Building the system that builds the software
I like to have a wide definition of agile that includes all of the many other things we need to create software.
A really common mistake I see teams making is foccussing on the Work Management side of Agile and neglecting the need for Technical Excellence. This especially prevelant if the implementation of agile is led by Agile Coaches.
With diagram above I'm attempting to show several things:
- All of the various topics and specialities that make up a modern SDLC (I'm sure I've missed plenty!)
- The differant techniques we use across Planning, Work Management, Development and Run
- The items that I think are absolutly essential (I'm 100% confident readers will disagree with my selections!)
Why is it important to present the various elements in this way? Because no matter how much effort we put in to building beautiful backlogs and well crafted stories - we'll never achieve significant velocity without a decent investmrnt in technical excellence.
It's also really common for teams to become sidetracked by activities in the Technical Excellence area. There's a good reason for this - working in this area is fun! It's why we became developers, and all (good) developers want to improve temselves and thier product, so it's natural to want to excel. But once again we need to continually ask ourselves - "Is this advancing the project".
The Toolbox Approach
What is the most efficient way of shipping quality software as part of a team?
This will obviously change dependant on the size oi the product and the size of the team, so that is why I suggest using a "toolbox" approach. Think of all of the items on the diagram as a set of tools in a toolbox, and pick the ones that you need for your particular scenario.
If you're like me (a homeowner of advancing years) you will have aquired a toolbox with a wide range of DIY essentials, as well as a few specialist items. Do I use every single tool in my toolbox when I attempt a DIY task? Of course not. I'm particularly fond of my power drill, but if I'm tasked with unblocking a toilet - it's a disasterous choice!
How does this apply to software projects? Well let's take an example of a small internal web app - maybe we've been tasked with creating a holiday booking system for our small organisation of arround 50 employees.
Immediately we can see that for a company of circa 50 employees we're unlikely to need to expend too much effort on load testing our product. We only have 50 potential users and they're unlikley to be using the product simultaneously. Even if our company experiences some serious growth it's unlikely our system will become stressesed for quite some time.
Let's pick some more easy ones from the diagram.
Daily Stand-Ups
Getting everyone together for 15 minutes to share progress and blockers seems like a no-brainer to me. It's especially helpful on time critical projects, and it's also a really good way of making everyoneone feel part of a team. I'd expect to use this technique on the vast majority of projects.
Note: If your daily stand-up is taking an hour every day it's not a stand-up - it's a daily hour long meeting. This is bad.
A/B Testing
I'm sure we'll want to provide our users with a slick and smooth UI, but how much business value do we expect to get from intense focus on UI for an internal business application?
A/B Testing really comes into it's own when fine tuning a large scale public facing application. If you can't directly contact your customers, A/B testing is a really clever technique for trying different options and seeing how the user reacts or adopts. In this scenario however we can just go and ask our user base - infact we may have to use the applicaion ourselves, so there's no obvious need for it.
Mob Programming
I've worked with teams that are extremely enthusiastic about the benefits of this approach, but it's hard to claim that it's essential. I personally like to use this tactic when you need a team to focus on resolving a live issue or a particularly challenging technical problem, but I feel that the majority of the time I'm far more productive working alone.
Continuous Integration
This falls into my Technical Excellence category, and is so straightforward to implement with modern toolsets, that it has to be a standard practice for all projects.
Summary
I've sensed a feeling in teams that they're "missing out" if they're not participating in all of the latest trends. But there are no "Agile Police", and no-one from your business unit has heard of some of these techniques - let alone is demanding them.
Relentlessly focus on shipping the product and only adopt a practice if it's going to help you:
- Go faster
- Reduce consistent errors (which slow you down)
- Significantly (and measurably) reduces risk